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Agenda 


1 .  Statement  of  Problem  and  Approach 

2.  Overview  of  Methodology 

3.  Status  of  Pilot  Tests 

4.  Observations 
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Definition 


We  define  interoperability  of  weapons  systems  electronics  as  the: 

•  Interchangeable  use  of  hardware  and  software  across  many 
kinds  of  weapons  and  commercial  systems 

•  Ability  of  weapons  systems  electronics  to  interoperate 
effectively  in  joint  operations 
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What  is  the  problem  we  are  addressing? 


♦  DoD’s  National  Defense  goal  is  to  sustain  superior  warfighting 
effectiveness  as  efficiently  as  possible, 

♦  But  currently,  our  weapons  systems: 

-  Have  problems  interoperating  with  each  other  and  with  C4I  systems 

-  Have  Unique  implementations  of  similar  functionality  leading  to 

•  Much  duplication  of  effort 

•  Problems  with  reliability,  maintainability  and  availability 

-  Costly:  closed  designs  lead  to  sole  source  products 

•  Minimal  use  of  COTS  products 

•  Lack  of  competitiveness  to  reduce  cost 

•  Increased  logistics  costs 
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How  Can  the  Problem  be  Attacked? 


♦  Use  the  Open  Systems  Approach  to: 

-  Reduce  the  life  cycle  costs  of  weapons  systems  electronics 
through  reuse  of  hardware/software  resulting  in: 

•  Increased  dependability:  mature  HW/SW  with  improved 
reliability,  maintainability  and  availability 

•  Increased  deployability:  mature  equipment  with  fewer 
support  needs 

-  Support  quicker  insertion  of  new  technology  across  weapons 
systems 

-  Improve  the  interoperation  of  weapons  and  C4I  systems 
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RAND’s  Idea  for  Addressing  the  Problem 


♦  The  technical  architecture  approach  developed  by  the  C4I 
community  might  be  extended  to  weapons  systems  electronics 

♦  We  may  be  able  to  formulate  a  practical  method  for  guiding  the 
development  of  Extended  Technical  Architectures  (ETAs)  for 
weapons  systems  electronics 
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Strategy  for  Improving  Interoperability 
Aims  To  Evolve  a  Methodology 
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The  Hypothesized  Role  of  an  Extended  Technical 
Architecture  (ETA)  for  Weapons  Systems  Electronics 


♦  Divide  DoD’s  weapons  systems  electronics  into  domains  and 
subdomains 

♦  For  each  weapons  systems  electronics  domain/subdomain 

-  Require  the  services  and  the  defense  agencies  to  develop  a  set 
of  rules  for  improving  interoperability 

-  Define  the  rules  for  a  domain  as  the  domain’s/subdomain’s 
extended  technical  architecture 

-  Use  the  extended  technical  architectures  to  develop  and 
review  acquisition/modification  programs  at  the  PEO,  Acq 
Exec,  and  OSD  levels 
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Agenda 

1 .  Statement  of  Problem  and  Approach 
— ►  2.  Overview  of  Methodology 

3.  Status  of  Pilot  Tests 

4.  Observations 
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A  Proposed  Structure  for  Organizing 
an  Extended  Technical  Architecture 


Technical 


Section  1:  Technical 


Operational  Architecture 
System  Architecture 
Technical  Architecture 

Management  Section  2:  Institutional 

Section  3:  Development,  validation,  and  evolution 
Section  4:  Maintenance  and  maturation 


Business 


Section  5:  Resources 
Section  6:  Schedule 
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Technical  Section  of  an  ETA  for 
Weapons  Systems  Electronics  (1  of  4) 

1.1  Operational  architectures:  answer  WHAT  the  domain’s 
weapons  systems  need  to  do  to  satisfy  operators’ 

warfighting  needs 

1.1.1  ♦  Domain  Operational  Architecture 

-  Functions  to  be  provided  by  the  domain’ s 
electronics,  and  their  interdependencies 

1.1.2  ♦  Domain  Software  Operational  Architecture 

-  Functions  to  be  provided  by  the  domain’ s 
software,  and  their  interdependencies 

1.1.3  ♦  Domain  Hardware  Operational  Architecture 

-  Functions  to  be  provided  by  the  domain’ s 
hardware,  and  their  interdependencies 
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Technical  Section  of  an  ETA  for  Weapons 
Systems  Electronics  (2  of  4) 

1.2  System  Architectures:  answer  HOW  the  domain’s  weapons 

systems  elements  will  be  arranged  to  satisfy  the  OA  needs 

1.2.1  ♦  Domain  system  architecture(s) 

-  Equipment  architectural  style(s)  for  the  domain:  the  general 
principles  for  arranging  the  electronics  hardware  and  software 
for  the  domain 

1 .2.2  ♦  Domain  software  system  architecture(s) 

-  Software  architectural  style(s)  for  the  domain:  the  general 
principles  for  arranging  the  software 

1 .2.3  ♦  Domain  hardware  system  architecture(s) 

-  Hardware  architectural  style(s)  for  the  domain:  the  general 
principles  for  arranging  the  hardware 
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Technical  Section  of  an  ETA  for 
Weapons  Systems  Electronics  (3  of  4) 

1,3  Interface  requirements 

1.3.1  ♦  Domain  interface  requirements 

-  Principles,  practices,  and  standards  to  be  adhered  to  in  the 
design  of  system  hardware  and  software  elements  compliant 
with  the  architectural  style 

1 .3.2  ♦  Domain  software  interface  requirements 

-  Principles,  practices,  and  standards  to  be  adhered  to  in  the 
design  of  system  software  compliant  with  the  architectural 
style 

1 .3.3  ♦  Domain  hardware  interface  requirements 

-  Principles,  practices,  and  standards  to  be  adhered  to  in  the 
design  of  system  hardware  compliant  with  the  architectural 
style 
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Technical  Section  of  an  ETA  for 
Weapons  Systems  Electronics  (4  of  4) 


1.4  ♦  Technical  reference  models  defining  the  entities 

addressed  by  the  technical  architecture 

1.5  ♦  Additional  standards  that  will  be  adhered  to  within 

the  domain 
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Institutional  Section  of  an  Extended 
Technical  Architecture  (1  of  2) 


2.1  ♦  Functions  of  institutions  that  are  required  to 

-  Develop,  validate,  evolve,  maintain,  and  mature  the  extended  technical 
architecture 

»  Requirements  for  organizations  and  weapons  systems  programs  to 
perform  life-cycle  management  tradeoffs 

♦  For  a  weapon  system 

♦  Across  weapons  systems 

♦  Across  services 

-  Apply,  incentivize  and  enforce  the  extended  technical  architecture 

2.2  ♦  Division  of  responsibility  and  authority  across  institutions  for 

providing  the  required  functions 
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Institutional  Section  of  an  Extended 
Technical  Architecture  (2  of  2) 

2.3  ♦  Interface  requirements  for  participating  institutions 

-  Guidelines  for  intra-domain  coordination  across  organizations  and 
programs 

-  Guidelines  for  inter-domain  coordination 

»  Extended  technical  architectures 
»  Organizations  and  programs 

-  Guidelines  for  incentives  and  enforcement 

♦  Current  documents  governing  the  participation  of 

2  4 

participating  institutions 

-  Guidance  from  higher  authorities 

-  Agreements  among  participating  institutions 
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Development,  Validation,  and  Evolution 
Section  of  a  Technical  Architecture 


3.1  ♦  Processes 

-  Technical  processes  involved  in  the  development,  validation, 
and  evolution  of  the  extended  technical  architecture 

»  These  might  include  tests  and  other  methods  that  address  the 
technical  content  of  the  extended  technical  architecture 

-  Milestones:  approval  by  Services,  defense  agencies  and 
OSD 

3.2  ♦  Roles  and  duties 

-  OSD:  funding  and  oversight 

-  Participating  services  and  defense  agencies 
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Maintenance  and  Maturation  Section  of  an 
Extended  Technical  Architecture 

4.1  ♦  Processes 

-  Activities 

»  Assessment 

»  Housekeeping  and  monitoring 
»  Research  and  refinement 

-  Milestones 

4.2  ♦  Roles  and  duties 

-  OSD 

-  Participating  services  and  defense  agencies 

-  Commercial  R&D,  standards,  etc. 
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Resource  Section  of  an  Extended 
Technical  Architecture 


5.1  ♦  Requirements  on  the  nature  and  extent  of  life-cycle 

management  tradeoffs  for  a  weapon  system 

-  Across  weapons  systems 

-  Across  services 

5.2  ♦  Approach  to  obtaining  and  managing  resources 

required  for  front-end  investments  that  enable 
development,  validation,  evolution,  maintenance, 
maturation,  implementation  and  enforcement  of 
technical  architectures 
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Schedule  Section  of  an  Extended 
Teehnieal  Arehiteeture 

6.1  ♦  Initial  establishment  of  the  extended  technical 

architecture 

6.2  ♦  Subsequent  maintenance  and  evolution 

6.3  ♦  Resolution  of  schedule  conflicts 
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Agenda 

1 .  Statement  of  Problem  and  Approach 

2.  Overview  of  Methodology 

— ►  3.  Status  of  Pilot  Tests 

4.  Observations 
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Pilot  Test  1:  Army  Aviation 

♦  Goals 

-  Improve  Interoperability 

-  Reduce  costs  across  Army  helicopter  systems  through 
common  use  of  hardware/software  to  be  implemented  during 
upgrades 

-  Promote  faster  insertion  of  new  technology 

♦  Approach:  develop  an  open  systems  architecture  for 
accomplishing  upgrades 

♦  Status: 

-  Began  working  with  Army  Aviation  in  February,  1998 

-  Initial  focus  is  on  common  mapping  subsystem 

-  Will  be  working  as  part  of  Army  Aviation  team  in  helping 
them  with  methodological  approach 


Pilot  Test  2:  Integrated  Diagnostics 

♦  Goals 

-  Improve  diagnostic  performance  to: 

»  Support  availability  of  increasingly  more  complex  systems 
»  Reduce  life  cycle  costs 

-  Promote  faster  insertion  of  diagnostic  technology 

♦  Approach:  develop  an  Open  Systems  Architecture  for 
standardizing  diagnostic  architectures,  methods,  and  equipment 

♦  Status: 

-  Began  working  with  DoD  Executive  Agent  for  Automatic  Test 
Equipment  (NAWC)  in  August,  1997 

-  Initial  focus  was  on  case  studies  to  profit  from  lessons  learned 

-  Current  focus  on  RAND  Workshop  on  Diagnostics,  May  4-7, 
Santa  Monica 
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RAND  Workshop  on  Diagnostics 
May  4-7,  Santa  Monica 

♦  Workshop  objective:  to  develop  an  Open  Systems  Architecture  and  standards 
for  excellence  in  Integrated  Diagnostics  for  large  scale  complex  products 

♦  Workshop  Steps 

1 .  Diagnostic  functions 

-  Identify  diagnostic  functions 

-  Divide  functions  into  functional  areas 

-  Identify  interfaces  between  the  functional  areas 

Results  in  defining  an  Open  Systems  Architecture  for  Diagnostics 

2.  Evaluate  current  systems  for  shortfalls  with  respect  to  the  Open  Systems 
Architecture  for  Diagnostics 

3.  Identify  opportunities  for  dealing  with  the  identified  shortfalls 

4.  Organize  opportunities  into  a  framework  for  addressing  improvements 

♦  Next  step:  package  the  Workshop  products  in  the  form  of  an  ETA  for 
Integrated  Diagnostics 
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Interesting  Observations 


♦  An  ARINC-like  facilitation  process  is  essential  to  facilitating  the 
development  and  maintenance  of  an  Extended  Technical  Architecture 
for  a  weapons  systems  domain 

♦  A  domain  advocate  is  critical  to  fostering  the  development  of  a 
weapons  systems  domain 

♦  For  a  domain  ETA  to  add  real  value,  the  acquisition  programs  within 
the  domain  needs  to  develop  and  own  the  ETA 

-  Basis  for  developing  common  domain  solutions  is  economic  feasibility 

-  Mandates  should  appear  in  the  Operational  Architecture  (in  being  clear 
about  what  has  to  be  done)  not  in  use  of  technical  standards 

♦  A  methodology  that  addresses  the  three  parts  of  an  ETA  (technical, 
management  and  business)  is  essential  to  the  effective  management  of  a 
weapons  systems  domain 
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Gebman,  and  Douglas  Mclver,  DRR-1579/1-OSD,  February, 

1997. 

“A  Strategy  for  Improving  Interoperability  of  Weapon  System 
Electronics,  Volume  2;  Strategy”,  Iris  Kameny,  Jean  Gebman, 
and  Douglas  Mclver,  DRR-1579/2-OSD,  February,  1997. 

“Fostering  Collaborations  Across  Industry  and  Acquisition 
Programs”,  Jean  Gebman,  Iris  Kameny,  and  Douglas  Mclver, 
PM-775-OSD,  January,  1998. 
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